1. Field of the Invention
The present invention relates to the execution of computer code components in a run-time environment and more particularly to class loaders in a run-time environment.
2. Description of the Related Art
The class loader mechanism forms part of the foundation of the modem, virtual machine. In particular, class loaders provide the translation technology which can convert serialized byte code into named classes for execution in the virtual machine. Notably, class loaders can perform this conversion regardless of the storage means and location of the byte code. As a result, the virtual machine need not know the operational specifics associated with the file systems storing the byte code.
In conventional runtime environments like the Java™ runtime environment (Java is a trademark of Sun Microsystems of Palo Alto, Calif., United States), classes can be introduced when they are referenced by name in a class that already is executing within the runtime environment. While the entry point class of an application can require some individual processing exclusive of the class loading mechanism, subsequent attempts at loading other classes are performed exclusively by the class loader.
At its simplest, a class loader creates a flat name space of class bodies that are referenced by a string name. For example, in the case of the Java runtime environment, a class loading definition might include:CLASS MYCLASS=LOADCLASS(STRING CLASSNAME,BOOLEAN RESOLVECLASS)
In this exemplary implementation of the loadClass( ) method, the variable className encapsulates a string which is understood by the class loader to uniquely identify a stored class implementation. The variable resolveclass, by comparison, is a flag which when set notifies the class loader that classes referenced by the class associated with the class name should be resolved. That is, any class referenced by the class associated with the class name should be loaded as well.
In the Java runtime environment, the Java virtual machine (JVM) can include one class loader embedded within the virtual machine. Referred to as the “primordial” class loader, this embedded class loader automatically resolves references to class names by reference to a specified repository of trusted classes which can be run by the virtual machine without verification. Notably, in the primordial class loader, a default implementation of the loadClass( ) method can be implemented.
The class loader generally is responsible for resolving a type within a given name space to an implementation of a class, and for loading the class into the virtual machine. If the same, identical type is loaded into two different name spaces through different class loaders, as represented by two different class instances, the type checking semantics of the environment inherently defines those types as incompatible. In consequence, a class case exception can be thrown.
As it is well-known in the art, different programming models can exist within a single run-time environment. Exemplary programming models can include a Java version 2.0 Enterprise Edition (J2EE) container and an Eclipse tools platform. Yet, each model can utilize different class loading semantics. In consequence, when it is necessary for the different programming models to interoperate with one another, exchange information with one another, and share services with one another within the same virtual machine, it can be necessary to bridge the name spaces in a manner to avoid class cast exceptions and to minimize the incurred communications overhead.
Specifically, when attempting to run components designed for different programming models inside a single virtual machine, it can be necessary to isolate and re-create the class loading semantics of the original model to enable the components to run unmodified. Isolating and re-creating the class loading semantics of the original model to enable component to run unmodified can be problematic, however. Also, altering the class loading semantics for the components of an application can require the componentization and deployment of the application in each of the environments in order to correctly load the shared interfaces from a common class loader. Of course, to do so can negate the goal and cost savings of not altering the existing programming models.